[file_selector] Switch to Kotlin Pigeon#11479
Conversation
Replaces the Java Pigeon generator with the Kotlin Pigeon generator, and adjusts the project accordingly: - Adds Kotlin build setings to Gradle. - Updates API signatures for Kotlin/Java differences. - Adds generic Java/Kotlin compat shim to create Result objects from Java, since those haven't been added to the Pigeon generator yet. - Updates tests to use constructors instead of builders, since the Kotlin generator doesn't create builders. - Updates tests to use a Java/Kotlin compat shim to read Kotlin Result values, instead of mocking the Java Pigeon response object. This does not attempt to fix the pre-existing invalid use of null paths described in flutter/flutter#159568, but the behavior does change slightly from an IllegalStateException (which came from the Java builder) to a NullPointerException (from trying to assign to a non-null Kotlin field). Part of flutter/flutter#158287
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request migrates the file_selector_android package to use Kotlin Pigeon for its internal implementation. Key changes include updating the CHANGELOG.md and pubspec.yaml for version and dependency updates, modifying build.gradle.kts to incorporate Kotlin plugins and compiler options, and replacing the Java-generated Pigeon API with a new Kotlin-generated one. Existing Java files (FileSelectorApiImpl.java, FileSelectorAndroidPlugin.java) are refactored to integrate with the new Kotlin API, including changes to method signatures and error handling. New Kotlin utility files (ResultUtils.kt, TestResultUtils.kt) are added to support Kotlin Result types and facilitate testing. The Dart-generated API (file_selector_api.g.dart) is also updated to reflect the new Pigeon version and error handling. A review comment highlights an incorrect package name in TestResultUtils.kt that needs to be corrected, along with its corresponding import in FileSelectorAndroidPluginTest.java.
|
|
||
| assertThrows( | ||
| IllegalStateException.class, | ||
| NullPointerException.class, |
There was a problem hiding this comment.
Isn't this a breaking change? How do we usually handle things like that?
There was a problem hiding this comment.
This is a grey area; either way it's a PlatformException on the Dart side, so it only breaks people doing string matching on the exact exception. When it's something that we've previously had as an intentional user-facing error that we expect them to handle, we have generally treated changing the exception internals as breaking and avoided doing it unless we are overhauling the plugin to use structure errors.
In this case, where it's an unintentional plugin bug (in an edge case), I don't think we need to assume people are string-matching the exception details and trying to handle it. Once once we fix the bug this will go away regardless.
| @@ -1,3 +1,7 @@ | |||
| ## 0.5.2+6 | |||
|
|
|||
| * Updates internal implementation to use Kotlin Pigeon. | |||
There was a problem hiding this comment.
Should we mention the NullPointer change?
There was a problem hiding this comment.
Since it's not an intentional behavior, I didn't think there was much to usefully document. It would have to say something like "The string details of the PlatformException reported in some rare failure cases have changed from referencing IllegalStateException to NullPointerException."
stuartmorgan-g
added
autosubmit
…er#185748) flutter/packages@ba80f8f...cde5b36 2026-04-29 stuartmorgan@google.com [file_selector] Switch to Kotlin Pigeon (flutter/packages#11479) 2026-04-29 stuartmorgan@google.com [image_picker] Switch to Kotlin Pigeon (flutter/packages#11504) 2026-04-29 stuartmorgan@google.com [quick_actions] Switch to Kotlin Pigeon (flutter/packages#11507) 2026-04-29 git@reb0.org [pigeon] fix: Apply correct ThrowError success callback (flutter/packages#11585) 2026-04-29 nateshmbhat1@gmail.com [video_player_platform_interface] Add video track selection support (flutter/packages#11474) 2026-04-29 katelovett@google.com Update git ignore for personal/iterating on agent skills and rules (flutter/packages#11600) 2026-04-29 stuartmorgan@google.com [file_selector] Update Windows example for deprecations (flutter/packages#11570) 2026-04-29 git@reb0.org [various] Upgrade googletest to v1.15.2 (flutter/packages#11586) 2026-04-28 engine-flutter-autoroll@skia.org Roll Flutter (stable) from cc0734a to 02085fe (2 revisions) (flutter/packages#11598) 2026-04-28 116356835+AbdeMohlbi@users.noreply.github.com [image_picker] Update documentation of maxDuration to reflect that it only applies to recording (flutter/packages#11417) 2026-04-28 suojae3@gmail.com [vector_graphics] add imageBuilder property to VectorGraphic (flutter/packages#11094) 2026-04-28 engine-flutter-autoroll@skia.org Roll Flutter from 61fca76 to 81bc3d6 (1 revision) (flutter/packages#11597) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-packages-flutter-autoroll Please CC flutter-ecosystem@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
3 participants
Replaces the Java Pigeon generator with the Kotlin Pigeon generator, and adjusts the project accordingly:
This does not attempt to fix the pre-existing invalid use of null paths described in flutter/flutter#159568, but the behavior does change slightly from an IllegalStateException (which came from the Java builder) to a NullPointerException (from trying to assign to a non-null Kotlin field).
Part of flutter/flutter#158287
Pre-Review Checklist
[shared_preferences]///).Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2